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Abstract 

The  Extended  Air  Defense  Testbed  (EADTB)  provides 
an  object-based  simulation  system  to  support  analysis 
of  current  and  future  extended  air  defense  systems  as 
they  interact  with  present  and  evolving  aircraft  and 
theater  missile  threats.  The  architecture  of  the  EADTB 
maps  real  world  objects,  such  as  aircraft,  missiles,  and 
radar,  into  software  simulation  objects  by  decomposing 
them  into  four  major  components. 


•  Thinker  Component  -  the  brain  of  the  object,  which 

performs  the  basic  functions  of,  observes  and 
decides. 


•  Platform  Component  -  the  physical  structure  of  the 
object 


•  Communicate  Component  -  the  means  of  passing 
data  from  one  object  to  another 


•  Sense  Component  -  the  means  of  seeking  data  of 
other  objects  or  conditions  external  to  the  Platform 


The  software  objects  are  linked  together  through  data 
definition  to  create  representations  of  real  world 
systems,  known  in  EADTB  as  Specific  System 
Representations  (SSRs).  An  SSR  contains  only  one 
Platform  component  and  at  least  one  Thinker 
component. 


The  data  which  comprises  an  SSR  essentially  defines 
the  physical  characteristics  of  the  represented  system, 
such  as  the  ability  to  move  (including  movement 


characteristics),  the  ability  to  detect,  to  generate 
signature,  and  to  harm  others.  The  ability  to  plan, 
coordinate,  and  react  is  contained  within  the  Thinker 
component  rule  set 


How  is  EADTB  different  from  other 
simulations? 

The  EADTB  offers  a  robust  user-flexible 
representation  of  weapons  systems,  sensors,  and  C4I 
systems  in  a  state-of-the-art  synthetic  environment  for 
NMD  and  TAMD  analyses.  The  EADTB  offers  a 
number  of  special  capabilities,  which,  in  combination, 
set  it  apart  from  other  simulations: 

1 .  EADTB  partitions  perception  from  truth  and 
propagates  perception,  whereas  many  simulations 
propagaate  truth  and  add  errors  to  represent 
perceptioa  EADTB  simulates  the  real-world 
processes  of  sensors  generating  perceived  data  and 
thinkers  making  decision  based  on  those  data. 

2.  The  EADTB  has  an  extensive  verification  and 
validation  (V&V)  legacy  for  library-resident 
specific  system  representations  (SSRs)  and  for  the 
common  model  set,  which  provides  the  “building 
blocks”  for  user  construction  of  SSRs. 

3.  EADTB  allows  users  to  build  their  own  SSRs,  as 
well  as  use  existing  SSRs  from  the  master  library. 
In  most  other  simulations,  the  user  can  only  set 
flags  or  modify  numerical  data  inputs  to  alter  the 
behavior  of  built-in  system  representations.  When 
built-in  representations  cannot  meet  user  needs, 
most  other  simulations  must  be  modified  by  the 
developer  or  altered  at  the  source-code  level  by  the 
user,  which  can  negate  any  existing  V&V 
verification. 

4.  The  EADTB  offers  a  high  degree  of  flexibility  in 
defining  the  detail  of  SSRs,  communications 
models,  environment  models,  and  the  scope  of  the 
scenario.  Scope  can  include  theater  level  for 
TAMD,  global  level  for  NMD,  or  simply  fire-unit 
level  for  one-on-few  simulations.  In  addition, 
EADTB  can  mix  different  levels  of  detail  in  a 
single  experiment.  For  example,  EADTB  could 
simulate  NMD  activities  at  low  detail,  theater  wide 
TAMD  at  low  detail,  and  a  single  fire  unit  or  ship 
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defending  a  critical  theater  “choke  point”  (e.g.,  a 
sea  port  at  a  relatively  high  level  of  detail  (e.g., 

3 DOF  flyout,  a  dynamic  sensor  with  Kalman  filter, 
extensive  C2  rule  sets,  and  explicit  communication 
message  format  representations). 

5.  The  EADTB  offers  the  capabilities  to  model 
command,  control,  communications,  computers, 
intelligence,  surveillance,  and  reconnaissance 
(C4ISR)  at  a  very  high  level  of  detail  for  a 
theater/global-level  simulation. 

6.  The  EADTB  offers  a  robust  suite  of  on-line  tools 
for  visualization  and  numerical  diagnostics. 
Visualization  capabilities  include  runtime  and 
playback  display  in  two-dimensional  (map)  view 
and  three-dimensional  view.  Playback  allows 
continuously  variable  forward  and  reverse  speeds. 
A  full  suite  of  spreadsheet  tools  and  statistical 
diagnostics  can  operate  on  user  specified  measures 
of  performance.  An  external  stealth  view  can 
easily  be  added  by  exploiting  the  EADTB’s  DIS 
compliance. 

SSR  Development 


SSR  development  follows  the  normal  flow  for  real 
system  development.  The  specific  system  to  be 
modeled  for  a  study  is  decomposed  into  its  most  basic 
functions  applicable  to  the  study  objectives.  These 
functions  are  collected  into  a  set  of  requirements  for  the 
specific  system  model  for  this  study.  Requirements 
levied  against  the  SSR  should  be  developed/modified 
for  the  study.  These  SSR  requirements  are  allocated 
against  the  SSR  data  and  rule  set.  The  requirements 
against  the  data  are  used  to  collect  appropriate  data 
and/or  derive  necessary  data  Rule  set  development  can 
follow  software  development  processes.  The  rule  set 
and  data  are  integrated  and  tested  on  the  EADTB  within 
a  small  scenario  to  identify  any  problems.  Finally,  the 
SSR  is  integrated  and  tested  in  the  study  scenario. 


The  EADTB  consists  of  an  array  of  software  modules 
linked  through  data  values  defined  during  Experiment 
Preparatioa  The  linkage  of  these  modules  allows  a 
wide  range  of  weapon  systems  to  be  modeled,  with  an 
emphasis  on  air  defense.  There  is  a  great  deal  of 
flexibility  in  the  modeling  of  these  systems.  For 
example,  the  user  has  access  to  many  predefined  SSRs 
contained  in  the  master  library,  or  the  user  can  construct 
completely  unique,  even  hypothetical  systems,  by 
defining  parametric  performance  data  for  a  system  and 
the  decision-making  logic  to  control  its  actions.  An 


SSR  is  defined  with  these  two  elements:  1)SSR  data 
sets  -  parametric  data  which  describe  the  functionality 
of  the  system;  and  2)SSR  rule  sets-  governs  which 
model  the  decision-making  logic  of  the  system. 


How  Rule  Sets  Anolv  to  the  Model 


Every  SSR  has  one  Platform,  one  or  more  Thinkers, 
and  zero  or  more  Sense  and  Communicate  components. 
While  the  Platform,  Sense,  and  Communicate 
components  perform  all  of  the  physical  functions  of  the 
modeled  systems,  all  of  these  functions  are  orchestrated 
by  the  Thinker  component  Thinker  can  be  thought  of 
as  a  knowledge-based  executive,  accepting  perceived 
data  as  input,  and  generating  action,  based  on  this  data, 
as  output  Thinker  has  access  to  data  including  assets, 
command  hierarchies,  tracks,  zones,  and  weapon 
resources.  The  Thinker  component  contains  decision 
logic,  known  as  its  rule  set,  which  it  uses  with  this  data 
to  decide  on  appropriate  commands  to  issue  to  other 
components,  and  how  to  process  data  received  from 
them. 


How  Data  Sets  Applies  to  the  Model 


The  SSR  data  sets  contain  all  of  the  parametric  data 
needed  to  define  the  operational  characteristics  of  the 
modeled  system.  The  type  and  extent  of  data  required 
depends  on  the  type  of  system  being  modeled.  The  data 
required  to  model  a  ballistic  missile  would  be  less  than 
that  needed  to  model  a  guided  missile  with  an  infrared 
(IR)  seeker. 


The  Thinker  parameters  include  performance  data  for 
kill  assessment,  guidance,  weapon  engagement,  threat 
assessment,  data  fusion,  and  command  reporting 
hierarchies.  The  Platform  data  consists  of  all  the  data 
needed  to  model  the  functions  of  Platform  -  move, 
carry/launch,  generate  signature,  and  impair/assess 
damage.  The  Communicate  data  consists  of  message 
protocol  and  format  data,  message  tables,  and 
connectivity  data,  including  nodes,  networks,  and 
gateways.  The  Sense  data  consists  of  all  the 
transmitter,  receiver,  tracker  and  discriminator 
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performance  data. 


SSR  Requirements 


Specification  of  requirements  for  EADTB  SSRs  is 
similar  to  the  specification  process  for  individual  and 
aggregated  representations  in  other  simulations.  The 
analyst  must  consider  study  requirements  and  actual 
weapon  system  requirements  to  identify  required 
control  logic,  input  data,  output  data,  measures  to  be 
quantified,  levels  of  accuracy  required,  and  any 
sensitivities  that  must  be  explored.  Sensitivities  may  be 
dictated  by  Measures  of  Effectiveness  and  Performance 
(MOEs/MOPs),  Essential  Elements  of  Analysis 
(EE As),  Critical  Operational  Issues  (COIs)  or  Critical 
Questions  and  Issues  (CQ&I)  of  the  study  that  the 
model  must  address.  Levels  of  detail  and  aggregation 
are  often  traded-off,  driven  by  the  model’s  execution 
speed  (i.e.  required  amount  of  time  to  process  all  runs) 
and/or  the  study  analysis  requirements. 


SSRs  also  have  requirements  for  compatibility  and 
interoperability  with  each  other,  which  are  driven  by 
the  EADTB  software  models.  Each  SSR  must  be 
capable  of  supplying  other  interacting  SSRs  required 
data  and  triggers.  These  items  include  parametric  data 
such  as  signature  and  lethality.  Communication 
between  SSRs  must  be  integrated  between  transmit  and 
receive  capabilities,  message  formats,  and  protocols. 
These  interoperability  requirements  alone  can  drive  the 
detail  and  accuracy  of  SSR  specifications. 


SSR  Integration  and  Test 


The  SSR  Integration  and  Test  (I&T)  is  performed  by 
the  developer.  The  test  vignette  defined  during  the 
preliminary  design  phase  is  used  during  the  SSR  I&T  to 
verify  the  functional  requirements  allocated  to  the  SSR, 
as  well  as  the  external  interfaces.  It  is  recommended 
that  new  SSRs  be  tested  in  sections.  With  successful 
integration,  actual  modules  of  the  SSR  are  coded  in 
proper  sequence.  This  iterative  process  continues  until 
all  requirements  and  interfaces  of  the  SSR  have  been 
integrated  with  the  test  scenario.  After  the  SSR  has 


been  successfully  integrated  and  tested,  a  test  walk¬ 
through  is  conducted. 


The  following  criteria  are  used  for  internal  review  of 
the  I&T  design: 


•  Ensure  all  functional  requirements  are  tested. 


•  Ensure  all  interfaces,  both  internal  and  external  are 
tested. 


•  Ensure  adequate  test  coverage  of  interfaces 
(minimum,  maximum  and  representative  value). 


Initial  SSR  I&T  may  be  accomplished  by  use  of 
internal  prompts.  This  level  would  serve  to  basically 
integrate  and  minimally  test  the  Platform  and  other 
attached  components  of  the  SSR.  For  example, 
prompts  could  be  established  during  the  Start  up  event 
to  trigger  required  rule  set  processing,  which  would 
result  in  subsequent  commands  issued  to  components 
component  data  access  and  retrieval,  and  the  setting  of 
additional  prompts. 


Further  SSR  I&T  is  accomplished  by  us  of  a  scriptor 
SSR.  This  level  serves  to  integrate  and  minimally  test 
message  reception  processing  in  the  tested  SSR.  The 
scriptor’s  rule  set  needs  to  be  written  such  that  all 
messages  expected  by  the  tested  SSR’s  rule  set  are 
transmitted.  Message  transmission  is  accomplished  via 
prompts,  via  Command  Complete  processing,  or  a 
combination  of  both.  Message  reception  processing  is 
then  monitored  and  evaluated  in  the  tested  SSR. 


Final  I&T  is  accomplished  by  deploying  the  subject 
SSR  in  a  test  scenario  with  other  SSRs.  At  this  level, 
complete  testing  of  all  functional  requirements, 
interfaces,  and  internal  processing  is  possible.  Much  of 
the  internal  processing  and  interface  testing  was 
completed  using  internal  prompts  and  scriptor  SSRs. 
The  bulk  of  test  during  this  phase  is  concentrated  on 
functional  requirements. 
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The  EADTB  offers  a  robust,  user-flexible 
representation  of  weapon  systems,  sensors,  and  C4I 
systems  in  a  state-of-the-art  synthetic  environment  for 
raid  and  multiple-raid  analyses. 


involves  comparing  EADTB  results  with  real  test  data. 
The  IV&V  team  utilizes  data  archived  in  the 
Midcourse  Data  Center  and  other  data  centers  to 
perform  output  validation. 


Systems  Represented  in  EADTB 


Current  Users  of  EADTB 


Specific  System  Representations  (SSRs)  are  user 
constructed,  so  any  system  falling  within  the  general 
classes  of  Guided  Missile,  Ballistic  Missile,  Orbital 
Space  Object,  Winged  Airborne  Movement  Object,  Sea 
Based  Movement  Object,  and  Ground  Movement 
Object  either  are,  or  can  be,  represented  Developers 
and  users  have  already  constructed  a  variety  of  SSRs 
associated  BM/C4I.  Recently  completed  SS^fhave 
assisted  in  the  assessment  of  space  information 
operations  communications/data  fusion  centers  and 
their  associated  surveillance  and  shooters.  Verification 
of  SSRs  is  an  on  going  process.  A  master  list  of  all 
SSRs  can  be  obtained  from  myself,  256-955-1650. 


Verification  &  Validation  Program  for  EADTB 


United  Kingdom  (UK),  MOD;  Germany,  IABG;  The 
Netherlands,  NATO  Consultation,  Command  and 
Control  Agency  (NC3A);  NATO  Medium  Extended 
Air  Defense  System  Management  Agency 
(NAMEADSMA);  USAADSCH,  Ft  Bliss  TX; 
USNSWC,  Dahlgren  VA;  USAF  TACCSF,  Kirkland 
AFB  NM;  BMDO,  4  sites  in  Washington  DC  area; 
USAAMCOM,  Huntsville  AL;  USASMDC  ARC  3 
sites,  Huntsville  AL;  Warfighter  Analysis  Integration 
Center  (WAIC),  Arlington  VA;  Lockheed  Martin 
Missile  and  Space,  Huntsville  AL  (1  in  AL  and  1  in 
FL);  SAIC,  McLean  VA;  Raytheon  Systems  Company 
(RSC)  Software  Development  Facility  (SDF), 
Huntsville  AL;  USASMDC  simulation  Center, 
Huntsville  AL 


The  TPO  has  had  an  Independent  V&V  (IV&V) 
program  and  dedicated  contractor  since  1993.  In 
addition,  experts  from  the  SETA  team  have  also  been 
used  to  perform  independent  V&V.  the  V&V  includes 
code  verification,  detailed  algorithm  analysis,  and 
output  validation  activities.  The  IV&V  contractor  has 
completed  detailed  analysis  reports  covering  the 
following  areas:  communications,  sensors,  ballistic 
missile  prediction,  missile  guidance,  data  tracker,  and 
plot  processing.  Regression  testing  is  performed  on 
new  releases  of  the  software  and  updated  reports  are 
submitted  as  required.  The  IV&V  contractor  has  tested 
over  4000  requirements  to  date. 


The  IV&V  team  performs  both  structural  and  output 
validation  on  EADTB.  Structural  validation  focuses  on 
the  architecture  and  algorithms  of  the  EADTB  in  the 
context  of  their  intended  use.  The  individual  functional 
areas  areas  are  evaluated  to  ensure  that  they  adequately 
represent  the  real  systems  being  modeled.  The 
algorithms  are  validated  to  be  correct  and  consistent 
with  established  theory.  Analyses  are  performed  to 
ensure  that  variations  in  the  inputs  produce  correct 
results  in  the  outputs.  The  total  simulation  is  assessed 
for  completeness  and  correctness.  Output  validation 
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Training,  Cost  &  Equipment 


An  EADTB/ Analysts  require  one  week  of  formal 
training  and  three  to  six  months  of  hands-on 
experience,  depending  of  the  background  of  the 
individual  to  be  trained  and  whether  the  individual  will 
be  developing  and/or  modifying  SSRs.  For  additional 
information  on  EADTB  training  contact  Raytheon 
Systems  Company  (Mr.  Rich  Stubblefield  256-971- 
2533)  or  the  TPO  (Mr.  Robert  Karl  256-955-1685)  to 
get  dates  of  classes  and  associated  costs. 


An  EADTB  system  with  up  to  two  workstations  costs 
approximately  S162K,  but  cost  will  vary  depending  on 
the  number  of  software  licenses  needed  and  the  number 
of  peripherals  and  additional  work  stations  required. 
Maintenance  cost  is  approximately  ten  percent  of 
purchase  price  per  year  of  operation. 


Hardware  and  Software  cost  for  a  typical  EADTB  Site 


A  typical  EADTB  site  includes  an  EADTB  host  system, 
at  least  two  EADTB  workstations,  system  software,  and 
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various  conunercial-off-the-shelf  (COTS)  software 
packages  used  in  configuration  with  EADTB  and 
Peripherals.  Currently,  the  recommended  EADTB  host 
system  is  a  Silicon  Graphics  Origin  2000,  with  4x250 
MHz  MIPS  R10000  CPUs,  2GB  RAM,  6x9  GB  SCSI 
Disk  Drives,  a  SCSI  XIO  card  and  external  vault,  fast 
ethemet  interface,  CDROM  and  4mm  DAT  Drive.  The 
recommended  EADTB  workstation  is  a  Silicon 
Graphics  02,  with  1x200  MHz  MIPS  R10000  CPU, 
384MB  RAM,  1x4.3GB  SCSI  Disk  drive  and  fast 
ethemet  interface.  The  EADTB  software  configuration 
requires  IRIX  Operation  System  and  NFS  for  both  the 
EADTB  host  system  and  the  EADTB  workstations. 

The  COTS  packages  include  Oracle  RDBMS  Version 
7.3.3  with  SQL  Plus  (including  SQL  Net  and  TCP/IP), 
PV-Wave  Advantage  6. 1  and  Applix  Base  and 
Spreadsheet  4.3.786.5.  Recommended  peripherals 
include  a  PostScript  Laser  Printer  and  Color  Printer,  A 
network  fast  ethemet  and  a  DLT  automatic  back-up 
system.  The  Testbed  Product  Office  (TPO)  is  also 
studying  use  of  the  Silicon  Graphics  Octane,  at  a 
greatly  reduced  cost,  but  which  will  only  support  one 
workstation. 
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